Введение

1. 
   Описание предприятия – объекта исследования
   

1. 
   Направление деятельности предприятия, отдела
   
2. 
   Описание жизненного цикла созданной базы данных на предприятии
   
3. 
   Структура базы данных предприятия, ее тип
   
4. 
   Какие программное обеспечение используется для работы и обращения с базой данных предприятия.
   
1. 
   Выполнение работ по Нормализации базы данных
   
2. 
   Выполнение работ по автоматизации T-SQL запросов
   

1.Ozon - ведущая универсальная e-commerce платформа в России. Оборот от продаж товаров и услуг (GMV) Ozon вырос на 74% год к году в третьем квартале 2022 года. Группа также управляет ведущим российским онлайн-турагентством Ozon. Travel, показатели которого не учитываются в GMV, и имеет долю в группе компаний «Литрес» — крупнейшей российской платформе электронных книг.

1.1. Продажа товаров и услуг

1.2 1. предварительное планирование

2. Определение требований

3. проектирование БД (концептуал логическое, физическое)

4. разработка приложений

5. реализация

6. загрузка данных

7. тестирование

8. эксплуатация и сопровождение
1.3.

Процесс проектирования информационных систем является достаточно сложной задачей. Он начинается с построения инфологической модели данных (п. 2), т.е. идентификации сущностей. Затем необходимо выполнить следующие шаги процедуры проектирования даталогической модели.

1. Представить каждый стержень (независимую сущность) таблицей базы данных (базовой таблицей) и специфицировать первичный ключ этой базовой таблицы.

2. Представить каждую ассоциацию (связь вида «многие-ко-многим» или «многие-ко-многим-ко-многим» и т.д. между сущностями) как базовую таблицу. Использовать в этой таблице внешние ключи для идентификации участников ассоциации и специфицировать ограничения, связанные с каждым из этих внешних ключей.

---

3. Представить каждую характеристику как базовую таблицу с внешним ключом, идентифицирующим сущность, описываемую этой характеристикой. Специфицировать ограничения на внешний ключ этой таблицы и ее первичный ключ – по всей вероятности, комбинации этого внешнего ключа и свойства, которое гарантирует «уникальность в рамках описываемой сущности».

4. Представить каждое обозначение, которое не рассматривалось в предыдущем пункте, как базовую таблицу с внешним ключом, идентифицирующим обозначаемую сущность. Специфицировать связанные с каждым таким внешним ключом ограничения.

5. Представить каждое свойство как поле в базовой таблице, представляющей сущность, которая непосредственно описывается этим свойством.

6. Для того чтобы исключить в проекте непреднамеренные нарушения каких-либо принципов нормализации, выполнить процедуру нормализации.

7. Если в процессе нормализации было произведено разделение каких-либо таблиц, то следует модифицировать инфологическую модель базы данных и повторить перечисленные шаги.

8. Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей.
1.4. Microsoft Access

2. Нормализация – это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации.

Как указывалось выше, каждая таблица в реляционной БД удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное атомарное значение, и никогда не может быть множества таких значений. Любая таблица, удовлетворяющая этому условию, называется нормализованной. Фактически, ненормализованные таблицы, т.е. таблицы, содержащие повторяющиеся группы, даже не допускаются в реляционной БД.

Таблица находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто.

Всякая нормализованная таблица автоматически считается таблицей в первой нормальной форме, сокращенно 1НФ. Как нетрудно заметить, все сконструированные нами ранее исходные таблицы БД учета заказов на ООО «Озон» заведомо находятся в первой нормальной форме.

---

Теория нормализации основывается на наличии той или иной зависимости между полями таблицы. Определены два вида таких зависимостей: функциональные и многозначные.

Функциональная зависимость. Поле В таблицы функционально зависит от поля А той же таблицы в том и только в том случае, когда в любой заданный момент времени для каждого из различных значений поля А обязательно существует только одно из различных значений поля В. Отметим, что здесь допускается, что поля А и В могут быть составными.

Полная функциональная зависимость. Поле В находится в полной функциональной зависимости от составного поля А, если оно функционально зависит от А и не зависит функционально от любого подмножества поля А.

Многозначная зависимость. Поле А многозначно определяет поле В той же таблицы, если для каждого значения поля А существует хорошо определенное множество соответствующих значений В.

Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.

Таблица находится в нормальной форме Бойса-Кодда (НФБК), если и только если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от возможного ключа.

Итак, можно сказать, что нормализация – это разбиение таблицы на несколько, обладающих лучшими свойствами при обновлении, включении и удалении данных. Можно дать и другое определение: нормализация – это процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в НФБК.

Рассмотрим таблицу Поставщики. Очевидно, что, поскольку все содержащиеся записи относятся к конкретному поставщику, которому присвоен уникальный КодПоставщика, то эта таблица находится во 2НФ, а так как каждое поле однозначно определяется этим уникальным кодом, то таблица находится и в НФБК. Аналогичные замечания полностью применимы к таблицам Клиенты и Сотрудники, которые, следовательно, также находятся в НФБК.

Рассмотрим далее таблицу Товары. Она находится в 1НФ. Первичным ключом таблицы является поле КодТовара. Зная значение ключевого поля, мы однозначно находим значения всех других полей таблицы. Это означает, что таблица в 2НФ. Заметим также, что все поля таблицы функционально зависят от поля КодТовара (ключевого), все поля функционально зависят от полей Наименование и КодПоставщика, но, поскольку по коду товара эти поля определяются однозначно, но данные зависимости сводятся к полной функциональной зависимости от первичного ключа. Следовательно, таблица также находится в НФБК.

---

Наиболее сложными для анализа являются таблицы Заказы и Заказано. Отметим сразу же, что поле Цена в таблице Заказано (отражающее отпускную цену товара покупателю) не совпадает с полем Цена в таблице Товары, где указывается закупочная цена товара.

Ключевым полем в таблице Заказы является поле КодЗаказа, оно действительно однозначно определяет все другие поля таблицы. Следовательно, таблица находится в 2НФ. Но, совершенно очевидно, что все другие поля (кроме КодКлиента и КодСотрудника) содержат только сведения о получателе заказа и дате его оформления и функционально зависят от ключевого поля. Поля же КодКлиента и КодСотрудника находятся в прямой функциональной зависимости от ключевого поля в силу самой конструкции рассматриваемой таблицы. Следовательно, она находится в НФБК. Что касается таблицы Заказано, то её ключевое поле является составным (КодЗаказа – КодТовара). Поскольку исключены повторения товаров водном и том же заказе, а цена каждого наименования товара оговаривается в каждом отдельном случае и однозначно определена этими двумя полями, то и эта таблица находится в НФБК.


3. Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть – ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других – нет, но логически такое разделение можно провести во всех СУБД. Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры «клиент-сервер» ядро является основной составляющей серверной части системы. Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является то, что языки этих систем являются непроцедурными, т.е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не является процедурой, а лишь описывает в некоторой форме условия совершения желаемого действия. Поэтому компилятор должен решить, каким образом выполнять оператор языка прежде, чем произвести программу. Требования, предъявляемые к современным СУБД:

---

Поддержка определённой логической модели данных.

Наличие встроенных языковых средств, в том числе:

а) язык определения данных – Data Definition Language(DDL).

б) языки манипулирования данных - Data Manipulation Language(DML).

в) язык запросов – Query Language(QL).

Наличие графического интерфейса, в котором можно выделить: интерфейс пользователя(User Interface), интерфейс разработчика(Developer Interface), интерфейс администратора(Administrator Interface).

Наличие подсистемы словаря данных и системного каталога.

Наличие программных средств контроля целостности данных.

Наличие средств разграничения доступа к данным.

Наличие средств документирования разрабатываемых проектов.

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

Microsoft Access – это функционально полная реляционная СУБД. В ней предусмотрены все необходимые средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. В Access существуют средства просмотра и манипулирования объектами базы данных:

- панель инструментов позволяет быстро выполнять команды создания, открытия и управления объектами базы данных;

- полоса объектов, предназначенная для просмотра объектов БД. Ее вертикальное расположение более удобно в использовании;

- ярлыки в окне базы данных ускоряют создание объектов с помощью Мастеров или открытие новых объектов в режиме Конструктора:

- настройка способов выбора и открытия объектов в окне базы данных;

К существующим возможностям, облегчающим работу с данными и проектирование базы данных, в среде Microsoft Access относятся следующие:

- поддерживается блокировка на уровне записей в дополнение к обычной блокировке, которая блокировала все записи на 4-кбайтной странице;

- можно свободно перемещаться между диалоговыми окнами поиска, замены и работы с данными;

- возможен просмотр и редактирование связанных записей в режиме таблицы (subdatasheet);

- автоматическое обнаружение ошибок переименования позволяет корректировать общие ошибки, вызванные переименованием форм, отчетов, таблиц, запросов, полей, текстовых боксов (text boxes) и других элементов управления;

- поддержка 16-разрядного стандарта кодировки символов Unicode;

- использование Microsoft ActiveX Data Objects (ADO) для доступа и манипулирования данными в базах данных сервера.

---

Смотрите также файлы

• Реферат на тему Противодействие коррупции в органах государственной власти и самоуправления.docx

• Образование древнерусского государства Киевская Русь.docx

• Требуется ли для размещения такой вывески получение разрешения органа местного самоуправления на установку рекламной конструкции.docx

• Российской Федерации Россиясвященная наша держава.doc

• Методические рекомендации по учету денежных средств на предприятиях малого агробизнеса авторы преподаватели гбпоу Иркутский аграрный техникум.doc