Студентки 4 курса учебной группы ЗФБЗ-06-15 ИВЗО



Юнцевич Елены Анатольевны

1. Практику проходила с 29.04.2019 по 25.05.2019 в__ФГБОУ ВО «МИРЭА – Российский   

технологический университет», на кафедре Промышленной информатике, студент    

(место прохождения практики и должность)

2. Задание на практику выполнил

в полном объеме                 _________________________________________________________

(указать: в полном объеме или частично)

Не выполнены следующие задания:

                                                             _---------------                                                               

(указать также причины невыполнения)

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

_________________________________________________________________________________

Предложения по совершенствованию организации и прохождения практики:

предложений нет                                                                                                                            

 

Студент _______________  (Юнцевич Е.А.)

             (подпись)         

«25»      мая 2019 г.

Заключение руководителя практики

Приобрел следующие профессиональные навыки: студент продемонстрировал профессиональные умения и навыки, знание и понимание прикладной области, задач, требующих решения в прикладной области, современные подходы и средства решения прикладных задач разных классов, умение находить и работать с различными источниками информации по профессиональной деятельности, структурировать отчет с учетом тематики исследования                                                                                                                                            

Проявил себя как: дисциплинированный ответственный специалист: соблюдал сроки календарного графика практики, регулярно отчитывался о проделанных этапах работ; за срок прохождения практики не получил ни одного замечания - проявляет инициативу, четко и в определенные сроки выполняет задания; в любой ситуации уважителен в общении с другими.

       «25»    мая   2019 г.

Отчет проверил:

Руководитель практики от Университета

 

__________________ (Панайоти В.А.)

                      (подпись)      


Оглавление

1. Введение. 7

2. Технология п роектирования базы данных. 7

3. Список литературы.. 15

 


 

Введение

В условиях современного производства, трудно представить научно-производственное предприятие без использования информационных систем. Большой объём разрабатываемых изделий требует хранения, обработки и поиска соответствующей документации на самых разных стадиях его жизненного цикла. В условиях переходного периода с неавтоматизированных, разрозненных АСУ на полноценную, современную связку АСУП «Парус ERP» и ADEM PDM/CAPP систему, существует необходимость учёта технологических процессов (ТП) и спецификаций (СП) в архиве отдела запуска изделий в производство.

Технология п роектирования базы данных.

 

Проектирование баз данных

Основные задачи проектирования баз данных

Основные задачи:

•     Обеспечение хранения в БД всей необходимой информации.

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

•     Сокращение избыточности и дублирования данных.

•     Обеспечение целостности базы данных.

Основные этапы проектирования баз данных

 

Концептуальное проектирование

Концептуальное проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных.

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

Концептуальная модель базы данных включает в себя:

· описание информационных объектов или понятий предметной области и связей между ними.

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

 


Логическое проектирование

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

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

На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.

Диаграмма классов – диаграмма, демонстрирующая классы системы, их атрибуты, методы и взаимосвязи с ними. Ниже показана структура базы данных с моделями.

Рис. 1. ER -диаграмма базы данных

Физическое проектирование

Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т. п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т. д.

Результатом физического проектирования логической схемы выше на языке SQL может являться следующий скрипт:

CREATE TABLE process_technologies

(

id serial NOT NULL,

detail character varying(30) NOT NULL,

cipher character varying(30),

name character varying(60),

receipts_date date,

correction_date date,

write_off_date date,

card_file boolean DEFAULT true,

written_off_process_technology_id integer,

created_at timestamp without time zone NOT NULL,

updated_at timestamp without time zone NOT NULL,

trade_secret boolean DEFAULT false,

CONSTRAINT process_technologies_pkey PRIMARY KEY (id),

CONSTRAINT fk_rails_46ca24daea FOREIGN KEY (written_off_process_technology_id)

REFERENCES written_off_process_technologies (id) MATCH SIMPLE

ON UPDATE NO ACTION ON DELETE NO ACTION

);

CREATE TABLE specifications

(

id serial NOT NULL,

specification character varying(30) NOT NULL,

cipher character varying(30),

name character varying(60),

  receipts_date date,

correction_date date,

write_off_date date,

card_file boolean DEFAULT true,

written_off_specification_id integer,

created_at timestamp without time zone NOT NULL,

updated_at timestamp without time zone NOT NULL,

trade_secret boolean DEFAULT false,

CONSTRAINT specifications_pkey PRIMARY KEY (id),

CONSTRAINT fk_rails_6bd7ef963b FOREIGN KEY (written_off_specification_id)

REFERENCES written_off_specifications (id) MATCH SIMPLE

ON UPDATE NO ACTION ON DELETE NO ACTION

);

Рис . 2. Пример скрипта создающего таблицы process_technologies и specifications.

Нормализация

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

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

Процесс преобразования отношений базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных. В одних случаях нормализация увеличивает производительность, в других — уменьшает; объём же базы данных при нормализации как правило уменьшается. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в базе данных информации. Как отмечает К. Дейт,[1] общее назначение процесса нормализации заключается в следующем:

•     исключение некоторых типов избыточности;

•     устранение некоторых аномалий обновления;

•     разработка проекта базы данных, который является достаточно «качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;

•     упрощение процедуры применения необходимых ограничений целостности.

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


Дата добавления: 2019-07-15; просмотров: 155; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!