Концепции за проектиране на база данни със SQL Server Management Studio (SSMS) Част 1

Тази статия е написана предимно за начинаещи. Все пак той обхваща някои интересни и често забравяни концепции за проектиране на бази данни, които са еднакво привлекателни за професионалистите по SQL бази данни.

Настоящата част се фокусира върху концепциите за проектиране на база данни и тяхното съпоставяне към таблици, колони и връзки на SQL база данни. Ако разбирате предисторията на базите данни и инструментите, които ще използваме, ще проектирате първата си SQL база данни с увереност.

Предварителни условия

Преди да продължим, уверете се, че имате следните неща:

1. SQL Server 2016/2017/2019 Express/Developer издание е инсталирано на вашето устройство
2. SSMS (SQL Server Management Studio) е инсталиран

Освен това трябва да имате основни познания за бази данни и горните инструменти.

Не е проблем, ако нямате най-новите версии на SQL Server и SSMS. Въпреки това е силно препоръчително да имате по-новите версии, ако не и най-новите налични. Можете да получите необходимите версии от ресурсите по-долу:

• Изтеглете SQL Server 2017 Developer Edition.
• Изтеглете SQL Server 2019 (като алтернатива, за да получите най-новото издание на SQL Server Express/Developer).
• Или изтеглете безплатно специализирано издание на Developer или Express SQL Server.
• Изтеглете SSMS (SQL Server Management Studio)

Имайте предвид, че всички тези връзки работят добре към момента на писане на тази статия. Ако Microsoft реши да ги замени, моля, изтеглете наличната по-нова версия.

Относно SQL дизайна на база данни

За да започнете да проектирате своята SQL база данни със SQL Server Management Studio (SSMS), трябва да имате някакъв план за проектиране в ума си.

Не е лесно без познаване на основните концепции за проектиране на база данни. Въпреки това, след като получите тези концепции и тяхното прилагане, вие естествено започвате да следвате принципите на проектиране. Това е често срещано при почти всички разработчици на бази данни.

Нека първо да преминем през някои основни концепции за дизайн на база данни. Не е лесно да обхванем всички в една статия, но имаме нужда от нещо, от което да започнем.

Разбираме типична база данни по отношение на следните неща:

1. Обекти
2. Атрибути
3. Взаимоотношения

Какво е обект?

Субект е всичко, което бизнесът или физическото лице биха искали да съхраняват в база данни. Например:

1. Клиент.
2. Поръчайте.
3. Продукт.

Можем да кажем, че Клиент е субект, ако бизнесът иска да го съхранява в структура на база данни за транзакционни, анализни и отчетни цели. По същия начин, Поръчка поставени от Клиента е също субект, ако бизнесът иска да види тази информация. Следователно тази информация трябва да бъде част от базата данни.

Въпреки това, Поръчка няма много смисъл без Продукт . Продукт, предлаган на Клиента, също е субект.

Как се съпоставя обектът в базата данни?

От гледна точка на базата данни, обект може да бъде съпоставен с таблица. По този начин, ако бизнесът се нуждае от обектите „Клиент“, „Поръчка“ и „Продукт“, разработчикът на база данни може да ги съпостави като три таблици.

Какво е атрибут?

Атрибутът е описание на обект. Например:

1. Име на клиента
2. Тип на поръчка
3. Име на продукт

Ако Клиентът е юридическо лице, името на клиента (CustomerName ) е атрибут. Този атрибут описва нашия обект (Клиент ). По същия начин, OrderType е атрибут на Поръчката обект и Име на продукт е атрибут на Продукта субект.

Как се съпоставя атрибутът в базата данни?

Атрибут, като CustomerName, описва Клиент таблица и може да бъде съпоставена с колона в тази таблица.

Обект с множество атрибути

Добре е един обект да има множество атрибути. Следователно можем да имаме много колони (атрибути) в таблица (обект).

Отношения на субекти

Един обект може да бъде свързан с друг обект чрез връзки. Една таблица може да бъде свързана с друга таблица. Има много видове обекти или таблични връзки:

Връзка клиент-поръчка (едно към много)

Клиент (субект/маса) може да бъде свързан с поръчка (субект/маса) поради следните причини:

1. Един клиент може да направи една поръчка.
2. Един клиент може да направи много поръчки.

Обратното също е вярно:

1. Много поръчки могат да бъдат направени от един клиент.
2. Една поръчка може да бъде направена от един клиент.

Това е пример за връзка един към много :един клиент може да направи много поръчки и много поръчки могат да бъдат направени от един клиент.

Връзка продукт-поръчка (едно към много)

Продукт (обект/таблица) може да бъде свързан с поръчка (обект/таблица) в следното:

1. Продукт може да бъде присвоен на една поръчка.
2. Един продукт може да бъде присвоен на много поръчки.

По същия начин:

1. Много поръчки могат да бъдат присвоени на продукт.
2. Една поръчка може да има един продукт.

Има връзка едно към много между Продукт и Поръчай .

Връзка клиент-продукт (много към много)

Сега връзката между клиент и продукт се обяснява по следния начин:

1. Един клиент може да закупи един продукт.
2. Един клиент може да закупи повече от един продукт.
3. Продукт може да бъде закупен от клиент.
4. Един продукт може да бъде закупен от повече от един клиент.

Много продукти могат да бъдат закупени от много клиенти, което означава, че Клиентът и Продукт връзката емного към много .

Разгледайте илюстрацията по-долу:

Сценарий за проектиране на студент-инструктор

Нека разгледаме различен сценарий за проектиране на база данни. Ще го приложите с помощта на SSMS (SQL Server Management Studio) в другата част на тази статия.

Бизнес изисквания

Да предположим, че трябва да проектирате база данни, която съхранява следната информация:

1. Студент(и).
2. Инструктор(и).
3. Студенти, на които е назначен инструктор.
4. Инструктори, които са назначени за учениците.

Предварителен анализ

При внимателно наблюдение ще откриете нещо доста интересно за горните изисквания. „Студентите, които са разпределили инструктор“ и „Инструкторите, които са назначени на студентите“ са едно и също изискване.

Може да се случи често две различно изглеждащи изисквания да се окажат еднакви в контекста на дизайна на база данни.

Идентифициране на обекти

Следните обекти могат незабавно да бъдат извлечени от изискванията:

1. Студент
2. Инструктор

Въпреки това, още един обект служи, за да ни предостави информация за инструкторите, разпределени на студентите.

Нека си припомним първия пример, в който използвахме таблица за поръчки – много клиенти могат да купуват много поръчки във връзката клиент-поръчка. Подобно е на нашия студент-инструктор таблична връзка – много преподаватели могат да бъдат разпределени на много студенти.

Идентифициране на атрибути

Можем да изберем полезни атрибути за идентифицираните субекти, според този сценарий на клиентска поръчка:

1. Студент:Студентска книжка, име.
2. Инструктор:идентификатор на инструктор, име.
3. Студент-инструктор:идентификатор на ученик-инструктор, идентификатор на ученик, идентификатор на инструктор.

Взаимоотношения на самоличността:

Идентифицирайте връзките на обектите:

1. Студент -> Студент-инструктор (един към много).
2. Инструктор-> Студент-Инструктор (един към много).
3. Студент -> Инструктор (много към много).

Не забравяйте, че винаги използваме средна маса, за да разрешим връзката много към много. Ето защо включихме обекта „Студент-инструктор“ в плана.

Отнасяне на обекти и атрибути към таблици и колони

Сега можем да съпоставим обектите в таблици. По този начин ще създадем следните три таблици:

1. Студент.
2. Инструктор.
3. Студент-инструктор.

По същия начин, атрибутите на тези обекти, когато са съпоставени с колоните, ще бъдат както следва:

1. Студент:StudentId, Name.
2. Инструктор:InstructorId, Name.
3. Студент-инструктор:StudentInstructorId, StudentId, InstructorId.

Обърнете внимание на илюстрацията по-долу:

Честито! Успешно сте научили концепциите за проектиране на база данни. Запознати сме с обектите, атрибутите и връзките и стъпките за тяхното съпоставяне с таблици и колони в базата данни.

Следващите статии ще ви преведат през стъпките за проектиране на база данни с помощта на SSMS (SQL Server Management Studio).

Неща за правене

След като вече сте разбрали основите на проектирането на база данни, опитайте следните неща, за да подобрите допълнително уменията си:

1. Опитайте да добавите друг обект, наречен Доставчик с атрибутите SupplierId и SupplierName. Проверете дали можете правилно да идентифицирате следните връзки:
   1. Доставчик-Поръчка;
   2. Доставчик-Клиент;
   3. Доставчик-продукт.
2. Проектирайте база данни заедно с идентифициране на обекти, атрибути и връзки за библиотека. Съвет:Книгите се издават на членовете, а членовете заемат книги от библиотеката. Член, книга, издаден могат да бъдат субекти.
3. Определете типа на следните таблични връзки за обектите, както е споменато по-горе:
   1. Издаден член;
   2. Издадена книга;
   3. Книга за членове;
   4. Член на книгата.

Прочетете също

Научете дизайн на база данни със SQL Server Management Studio (SSMS) – част 2