Определение атрибутов сущностей модели базы данных информационной подсистемы
Атрибут (реквизит) – именованная характеристика сущности [15]. Он представляет собой логически неделимый элемент структурной единицы информации, отражающий определенное свойство объекта или процесса. Атрибут идентифицирует экземпляры сущности.
Определим атрибуты выбранных сущностей (таблица 2.2)
Таблица 2.1 – Описание атрибутов сущностей модели базы данных информационной подсистемы
Наименование сущности | Описание сущности |
Сведения об организации | Сведения об организации |
Виды товаров | Справочник, в котором содержатся виды товаров, реализуемых предприятием (классификация товаров) |
Номенклатура товаров | Справочник, в котором содержатся сведения о реализуемых товарах |
Сотрудники | Справочник, содержащий информацию о сотрудниках отдела продаж предприятия |
Товары в наличии | Товары, находящиеся в наличии. Их количество |
Журнал продаж | Журнал, в который заносится информация о проданных товарах |
Список проданных товаров | Список товаров, указанных в накладной, относящиеся к записи в журнале продаж |
Единицы измерения | Единицы измерения товаров, реализуемых предприятием |
Поставщики | Поставщики товаров для предприятия |
Таблица 2.2 – Описание атрибутов сущностей модели базы данных информационной подсистемы
Название сущности | Атрибут | Описание атрибута | ||
Сведения об организации | Название организации | Название организации, предприятия | ||
ИНН | ИНН организации | |||
КПП | КПП организации | |||
Руководитель организации |
|
|
Поставщики
Вид товаров
Номенклатура товаров
Сотрудники
Товары в наличии
|
|
Журнал продаж
Список проданных товаров
Единицы измерения
2.2.3 Определение зависимостей между сущностями
|
|
Модель «сущность-связь» называют также методом ER — диаграмм (Essence - сущность, Relation - связь). Эта модель основана на использовании 3-х основных конструктивных элементах:
1) сущность;
2) атрибут;
3) связь.
Взаимосвязи между таблицами БД могут быть типизированы по следующим основным видам:
1. Отношение «один к одному» (1:1) означает, что каждая запись одной таблицы соответствует только одной записи в другой таблице.
2. Отношение «один ко многим» (1:М) возникает, когда одна запись взаимосвязана со многими другими.
3. Отношение «многие к одному» означает, что многие записи связаны с одной (М:1).
4. Отношение «многие ко многим» (M:N) возникает между двумя таблицами в тех случаях, когда:
- одна запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;
- одна запись из второй таблицы может быть связана более чем с одной записью из первой таблицы.
На практике применение связей 4 встречается крайне редко из-за того, что потеря в производительности вычислений на основе связей данного типа достаточна значительна.
В созданной модели встречаются связи типа 2 (отношение «один ко многим»). Они описаны в таблице 2.3.
Таблица 2.3 – Связи между сущностями
|
|
Номер связи | Родительская таблица | Дочерняя таблица | Тип связи |
1 | Сотрудники | Журнал продаж | 1:М |
2 | Журнал продаж | Список проданных товаров | 1:М |
3 | Номенклатура товаров | Список проданных товаров | 1:М |
4 | Вид товаров | Номенклатура товаров | 1:М |
5 | Номенклатура товаров | Товары в наличии | 1:М |
6 | Поставщики | Товары в наличии | 1:М |
7 | Единицы измерения | Номенклатура товаров | 1:М |
Сущность «Сведения об организации» не связана с другими сущностями. В этой сущности предполагается только одна запись о собственной организации.
Схема инфологической модели представлена на рисунке 2.1.
|
Рисунок 2.1 – Схема инфологической модели
На схеме изображены связи:
1. Сотрудники – Журнал продаж, тип связи 1:М (один сотрудник может оформить много продаж)
2. Журнал продаж – Список проданных товаров, тип связи 1:М (при одной операции продажи может быть продано много товаров).
3. Номенклатура товаров – Список проданных товаров, тип связи 1:М (товары одной номенклатуры могут продаваться много раз)
4. Вид товара – Номенклатура товаров, тип связи 1:М (в номенклатуре может быть много товаров одного вида)
5. Номенклатура товаров – товары в наличии, тип связи 1:М (товаров в наличии одной номенклатуры может быть много).
6. Поставщики – Товары в наличии, тип связи 1:М (товаров в наличии одного поставщика может быть много).
7. Единицы измерения – Номенклатура товаров, тип связи 1:М (может быть много товаров одной единицы измерения).
2.3 Даталогическое проектирование
2.3.1 Проектирование таблиц и их атрибутов
Проектирование базы данных будем осуществлять с использованием СУБД Microsoft SQL Server 2008. На сегодняшний день данная СУБД вышла в лидеры на рынке программных средств данного класса, потеснив даже такого гиганта как Oracle.
На основе разработанных сущностей были разработаны соответствующие им таблицы в базе данных с соответствующими атрибутами (таблица 2.4).
Таблица 2.4 – Перечень таблиц и атрибутов в базе данных
Название таблицы | Название атрибута | Тип данных | Краткое описание атрибута | |||
contragent (поставщики)
| contragent_id | int | Идентификатор поставщика | |||
contragent_name | varhcar(256) | Название поставщика | ||||
contragent_inn | varhcar(12) | ИНН поставщика | ||||
Goods (номенклатура товаров) | good_id | int | Идентификатор товара | |||
good_name | varhcar(50) | Название товара | ||||
Goods (номенклатура товаров) | type_good_id | int | Идентификатор вида товара | |||
pict_number | varhcar(50) | Чертежный номер | ||||
measure_id | int | Идентификатор единицы измерения | ||||
good_note | varhcar(50) | Описание товара | ||||
price | float | Продажная цена | ||||
goods_in_sell (Список проданных товаров) | good_in_sell_id | int | Идентификатор списка товаров | |||
good_id | int | Идентификатор товара | ||||
journal_sell_id | int | Идентификатор записи в журнале продаж | ||||
price_sell | float | Цена, по которой был продан товар | ||||
count_goods | int | Количество единиц проданного товара | ||||
goods_in_store (товары в наличии) | goods_in_store_id | int | Идентификатор записи | |||
good_id | int | Идентификатор товара | ||||
count_good | int | Количество единиц товара в наличии | ||||
contragent_id | int | Идентификатор поставщика | ||||
journal_sell (журнал продаж) | journal_sell_id | int | Идентификатор записи в журнале продаж | |||
date_sell | datetime | Дата продажи | ||||
journal_sell (журнал продаж) | customer | varchar(256) | Название организации - покупателя | |||
customer_fio | varhcar(50) | Фамилия покупателя (получившего товар) | ||||
people_id | int | Идентификатор сотрудника | ||||
measure (единицы измерения) | measure_id | int | Идентификатор единицы измерения | |||
measure | varhcar(50) | единица измерения | ||||
org_attr (сведения об организации) | name_org | varhcar(256) | Название организации | |||
org_boss | varhcar(256) | Руководитель организации | ||||
org_inn | varchar(12) | ИНН организации | ||||
org_kpp | varchar(50) | КПП организации | ||||
adres | varchar(256) | Юридический адрес организации | ||||
people (сотрудники) | people_id | int | Идентификатор сотрудника | |||
people_fio | varchar(50) | Фамилия сотрудника | ||||
dolg | varchar(50) | Должность сотрудника | ||||
type_good (вид товара) | type_good_id | int | Идентификатор вида товаров | |||
type_good | varchar(50) | Вид товара | ||||
Все идентификаторы в таблицах, имеющие тип int, имеют спецификацию идентификатора с шагом приращения 1. Это позволяет избежать создания триггеров, обеспечить целостность базы данных.
Схема базы данных представлена на рисунке 2.2.
Рисунок 2.2 – Диаграмма базы данных информационной подсистемы «Granit» на физическом уровне
2.3.2 Организация защиты данных на уровне СУБД
Защита данных на уровне СУБД выполняется средствами идентификации пользователя с помощью политики паролей.
Для создания нового пользователя администратору Microsoft SQL Server необходимо создать имя входа в разделе «Безопасность» (рисунок 2.3).
После создания имени входа необходимо предоставить пользователю соответствующие права на базу данных в разделе «Безопасность» базы данных GRANIT (рисунок 2.4).
Для работы с базой данных пользователю необходимо предоставить права db_datareader, db_datawriter.
Рисунок 2.3 – Создание имени входа
Таким образом пользователь не будет иметь возможность модифицировать структуру базы данных, но будет обладать всеми правами на данные, содержащиеся в таблицах.
Рисунок 2.4 – Установка прав на базу данных
Дата добавления: 2018-09-22; просмотров: 1154; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!