- •Содержание
- •Глава 1. Анализ предметной области асу «Библиотека».
- •1.1. Системный анализ предметной области.
- •1.2. Обзор информационных технологий, подходящих для разработки бд.
- •Классификации субд.
- •1.3. Требования к разрабатываемой базе данных.
- •1.4. Выводы.
- •Глава 2. Проектирование базы данных «Библиотека».
- •2.1. Разработка инфологической модели.
- •2.2. Обоснование выбора модели данных.
- •Сетевая модель.
- •Иерархическая модель.
- •Объектно-ориентированная модель.
- •Реляционная модель.
- •Многомерные структуры.
- •2.3. Логическое проектирование бд.
- •2.4. Нормализация, схема базы данных.
- •2.5. Выводы.
- •Глава 3. Программная реализация бд «Библиотека».
- •3.1. Анализ и выбор субд.
- •3.2. Физическое проектирование бд.
- •3.3. Реализация ограничений.
- •Создание пользователей.
- •Создание внешних ключей.
- •Создание ограничения.
- •Создание триггеров.
- •3.4. Безопасность и контроль.
- •Общая концепция безопасности.
- •Защищаемые объекты в sql Server.
- •Участники в sql Server.
- •Параметры проверки подлинности sql Server.
- •Участники уровня базы данных.
- •Разрешения в sql Server.
- •Шифрование баз данных.
- •3.5. Выводы.
- •Программный код.
- •Запросы на создание таблиц.
- •Запросы на заполнение таблиц.
- •Заключение.
- •Список литературы.
2.3. Логическое проектирование бд.
Для логического проектирования выбрана реляционная модель данных, т.к. она наиболее полно соответствует требованиям, предъявленным к разрабатываемой информационной системе:
отсутствие дублируемой информации;
поддержание целостности данных при вставке, удалении или изменении записей;
возможность организации всех видов связи между отношениями 1:1, 1:M и M:M.
В реляционной базе данных даталогическое проектирование приводит к разработке корректной схемы базы данных, т.е. такой схемы, в которой отсутствуют нежелательные зависимости между атрибутами. При этом можно использовать процесс проектирования с помощью декомпозиции, т.е. последовательно нормализовывать схему отношений, тем самым накладывая ограничения и избавляясь от нежелательных зависимостей между атрибутами.
В реляционных базах данных (РБД) даталогическое проектирование приводит к разработке схемы БД, т.е. совокупности схем отношений, адекватно моделирующих объекты ПО и семантических связей между ними.
Основой анализа корректности схемы являются функциональные зависимости между атрибутами БД. Некоторые могут быть нежелательными.
В конце этого этапа должно быть получено описание схемы БД в терминах выбранной СУБД. Целью даталогического проектирования является построение корректной схемы БД, ориентированную на реляционную модель. Корректной называется схема БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений.
Процесс разработки корректной схемы РБД и является даталогическим проектированием. Возможны 2-а способа:
Декомпозиция (разбиение).
Синтез.
Для перехода от инфологической модели к реляционной существует специальный алгоритм:
1. каждой сущности ставится в соответствие отношение;
2. каждому атрибуту сущности ставится в соответствие соответствующий атрибут соответствующего отношения;
3. первичный ключ сущности становится PK соответствующего отношения, при этом атрибуты, входящие в PK, обязательны для заполнения (NOTNULL);
4. в каждое отношение, соответствующее подчинённой сущности, добавляется набор атрибутов основной сущности, являющийся в ней первичным ключом. В отношении, соответствующее подчинённой сущности эти атрибуты становятся FK (внешним ключом);
5. по умолчанию, все атрибуты, не входящие в PK, необязательны;
6. для отражения категоризации сущностей возможны несколько вариантов;
7. все связи М:М должны быть раскрыты;
Воспользуемся данным алгоритмом и опишем каждую сущность инфологической модели:
Таблица 1. Subject.
Название столбца. |
Тип данных. |
NULL/NOT NULL |
ID_subject (PK) |
INT |
NOT NULL |
subject |
NVARCHAR(100) |
NOT NULL |
Таблица 2. Books.
Название столбца. |
Тип данных. |
NULL/NOT NULL |
ID_book (PK) |
INT |
NOT NULL |
ID_subject (FK) |
INT |
NOT NULL |
book_name |
NVARCHAR(100) |
NOT NULL |
annotation |
TEXT |
NULL |
year_of_publication |
VARCHAR(4) |
NOT NULL |
publisher |
NVARCHAR(100) |
NOT NULL |
number_of_racks |
NVARCHAR(50) |
NOT NULL |
number_of_books |
INT |
NOT NULL |
books_in_use |
TINYINT |
NOT NULL |
Таблица 3. Authors.
Название столбца. |
Тип данных. |
NULL/NOT NULL |
ID_author (PK) |
INT |
NOT NULL |
a_last_name |
NVARCHAR(35) |
NOT NULL |
a_first_name |
NVARCHAR(35) |
NOT NULL |
a_patronymic |
NVARCHAR(35) |
NULL |
year_of_birth |
VARCHAR(4) |
NOT NULL |
Таблица 4. Customers.
Название столбца. |
Тип данных. |
NULL/NOT NULL |
ID_customers (PK) |
INT |
NOT NULL |
c_last_name |
NVARCHAR(35) |
NOT NULL |
c_first_name |
NVARCHAR(35) |
NOT NULL |
c_patronymic |
NVARCHAR(35) |
NULL |
date_of_birth |
DATE |
NOT NULL |
phone_number |
INT |
NOT NULL |
home_address |
NVARCHAR(150) |
NOT NULL |
Таблица 5. Books in use.
Название столбца. |
Тип данных. |
NULL/NOT NULL | |||
ID_book (FK) |
(PK) |
INT |
NOT NULL | ||
ID_customers (FK) |
INT |
NOT NULL | |||
date_of_issue |
DATE |
NOT NULL | |||
return_date |
DATE |
NOT NULL |
Таблица 6. Author-Subject.
Название столбца. |
Тип данных. |
NULL/NOT NULL | |
ID_author (FK) |
(PK) |
INT |
NOT NULL |
ID_subject (FK) |
INT |
NOT NULL |
Таблица 7. Book-Author.
Название столбца. |
Тип данных. |
NULL/NOT NULL | |
ID_book (FK) |
(PK) |
INT |
NOT NULL |
ID_author (FK) |
INT |
NOT NULL |
Построим схему получившейся БД (Рисунок 5):
Рисунок 5. Схема реляционной модели БД «Библиотека».