производ практика 2. ПрП2. Введение Данная практика важна для закрепления теоретических знаний. Во время производственной практики были освоены этапы сбора, систематизации, анализа данных. Целью производственной практики является
 Скачать 0.58 Mb.
|
ВведениеДанная практика важна для закрепления теоретических знаний. Во время производственной практики были освоены этапы сбора, систематизации, анализа данных. Целью производственной практики является: формирование общих и профессиональных компетенций; комплексное освоение обучающимися видов профессиональной деятельности; приобретение студентами профессиональных навыков и первоначального опыта в профессиональной деятельности; закрепление и углубление знаний, полученных обучающимися во время аудиторных занятий; формирование основных профессиональных компетенций в соответствии с ФГОС СПО по профессии; воспитание сознательной трудовой и производственной дисциплины; Задачи практики: ввод и обработка цифровой информации; хранение, передача и публикация цифровой информации и соответствующих профессиональных компетенций (ПК); основы предпринимательства, открытие дела выпускниками Производственная практика проходила в ООО «Агроторг». Структура компании ООО «Агроторг» ООО «Агроторг» - общество с ограниченной ответственностью представляет собой сеть магазинов розничной торговли «Пятёрочка». Миссия компании - обеспечение населения бытовыми товарами и продуктами. Структура целей организации: 1. Открытие новых магазинов в других регионах страны; 2. Совершенствование технологий по продаже бытовых товаров и продуктов; 3. Совершенствование технологий по сохранению скоропортящихся продуктов; 4. Увеличение продаж данной продукции; 5. Обеспечение работой населения в сети магазинов. Организационная структура ООО «Агроторг» приведена на рисунке  Рисунок 1 - Организационная структура управления ООО «Агроторг» ООО «Агроторг» возглавляет генеральный директор. Генеральный директор руководит в соответствии с действующим законодательством производственно-хозяйственной и финансово- экономической деятельностью предприятия, неся всю полноту ответственности за последствия принимаемых решений, сохранность и эффективное использование имущества предприятия, а также финансово- хозяйственные результаты его деятельности. В непосредственном подчинении генерального директора находятся: ИТ-отдел, бухгалтерия, отдел маркетинга, коммерческий отдел. Генеральный директор организует работу и эффективное взаимодействие всех перечисленных структурных подразделений. Осуществление закупок входит в обязанности коммерческого отдела. Коммерческий отдел непосредственно подчиняется руководителю отдела. ИТ-отдел занимается обеспечение технической стороны функционирования ООО «Агроторг». В обязанности отдела входит: ведение технического учета работы различного торгового оборудования; осуществление контроля за соблюдением нормативных расходов материалов; оборудования. К функциям отдела маркетинга ООО «Агроторг» относятся следующие: Исследование рынков фирмы. Построение информационной системы маркетинга в компании; Конкурентное позиционирование компании и ее продуктов на целевых рынках; Организация обратной связи с клиентами, оценка уровня их удовлетворенности; Формирование лояльности клиентов к компании, развитие маркетинга партнерских отношений. Общие функции маркетинга осуществляет руководитель отдела маркетинга — это управление, организация, планирование, прогнозирование и целеполагание, анализ, оценка, учет и контроль маркетинговой политики. Рабочее место  Характеристики компьютера: Intel Core-I5 1155 8 Гб RAM 256 Гб SSD Клавиатура и мышь Монитор 24 дюйма Windows 10 Pro Что такое база данных? База данных — это место для хранения данных. Используется в том числе в клиент-серверной архитектуре Это все интернет-магазины, сайты кинотеатров или авиабилетов... Вы делаете заказ, а система сохраняет ваши данные в базе.  Также можно и дать такое определение, База данных (БД) — именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области. Под предметной областью принято понимать некоторую область человеческой деятельности или область реального мира, подлежащих изучению для организации управления и автоматизации, например, предприятие, вуз и.т.д. Что такое СУБД? Виды БД. Система управления базами данных (СУБД) — совокупность языковых и программных средств, предназначенных для создания, наполнения, обновления и удаления баз данных. Основополагающими понятиями в концепции баз данных являются обобщенные категории «данные» и «модель данных». Понятие «данные» в концепции баз данных — это набор конкретных значений, параметров, характеризующих объект, условие, ситуацию или любые другие факторы, Примеры данных: Петров Николай Степанович, $30 и т. д. Данные не обладают определенной структурой, данные становятся информацией тогда, когда пользователь задает им определенную структуру, то есть осознает их смысловое содержание. Поэтому центральным понятием в области баз данных является понятие модели. Не существует однозначного определения этого термина, у разных авторов эта абстракция определяется с некоторыми различиями но, тем не менее, можно выделить нечто общее в этих определениях. Модель данных — это некоторая абстракция, которая, будучи приложима к конкретным данным, позволяет пользователям и разработчикам трактовать их уже как информацию, то есть сведения, содержащие не только данные, но и взаимосвязь между ними. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними. В зависимости от вида организации данных различают следующие важнейшие модели БД: иерархическую сетевую реляционную объектно-ориентированную В иерархической БД данные представляются в виде древовидной структуры. Подобная структура БД удобна для работы с данными, упорядоченными иерархически. При оперировании данными со сложными логическими связями иерархическая модель оказывается слишком громоздкой. В сетевой БД данные организуются в виде графа. Недостатком сетевой структуры является жесткость структуры и сложность ее организации. Реляционная БД получила свое название от английского термина relation (отношение). Была предложена в 70-м году сотрудником фирмы IBM Эдгаром Коддом. Реляционная БД представляет собой совокупность таблиц, связанных отношениями. Достоинствами реляционной модели данных являются простота, гибкость структуры. Кроме того ее удобно реализовывать на компьютере. Большинство современных БД для персональных компьютеров являются реляционными. Объектно-ориентированные БД объединяют сетевую и реляционную модели и используются для создания крупных БД с данными сложной структуры. Базы данных можно разделить на базы данных первого поколения: иерархические, сетевые; второго поколения: реляционные; третьего поколения: объектно-ориентированные, обектно-реляционные. 5. Основы проектирования БД Разработанная функциональная модель системы отвечает на вопросы «Что должна делать система?» и «За счет каких действий может быть достигнут требуемый результат?». Эта модель также позволяет концептуально определить наборы данных, используемых в системе. В то же время она не отвечает на вопрос «Каким образом организованы данные в системе?». Для ответа на него необходимо построить информационную модель (запроектировать БД). Традиционно процедуру проектирования базы данных разбивают на три этапа, каждый из которых завершается созданием соответствующей информационной модели. Этап 1-й. Концептуальное проектирование – создание представления (схемы, модели) БД, включающего определение важнейших сущностей (таблиц) и связей между ними, но не зависящего от модели БД (иерархической, сетевой, реляционной и т. д.) и физической реализации (целевой СУБД). Этап 2-й. Логическое проектирование – развитие концептуального представления БД с учетом принимаемой модели (иерархической, сетевой, реляционной и т.д.). Этап 3-й. Физическое проектирование – развитие логической модели БД с учетом выбранной целевой СУБД. Концептуальное и логическое проектирование вместе называют также инфологическим или семантическим проектированием. В настоящее время для проектирования БД активно используются CASE-средства, в основном ориентированные на использование ERD (Entity – RelationshipDiagrams, диаграммы «сущность–связь»). С их помощью определяются важные для предметной области объекты (сущности), отношения друг с другом (связи) и их свойства (атрибуты). Следует отметить, что средства проектирования ERD в основном ориентированы на реляционные базы данных (РБД), и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы проектирования. ERD были впервые предложены П. Ченом в 1976 г. Основные элементы ERD перечислены ниже . Сущность (таблица, в РБД – отношение) – реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению. Если выражаться точнее, то это не объект, а набор объектов (класс) с одинаковыми свойствами. Примеры сущностей: работник, деталь, ведомость, результаты сдачи экзамена и т. д. Экземпляр сущности (запись, строка, в РБД – кортеж) – уникально идентифицируемый объект. Связь – некоторая ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Примерами связей могут являться родственные отношения «отец–сын», производственные – «начальник-подчиненный» или произвольные – «иметь в собственности», «обладать свойством». Атрибут (столбец, поле) – свойство сущности или связи. Большинство современных CASE-средств моделирования данных, как правило, поддерживает несколько графических нотаций построения информационных моделей. В частности система ERwin фирмы Computer Associates поддерживает две нотации: IDEF1X и IE (англ. Information Engineering – информационное проектирование). Данные нотации являются взаимно-однозначными, т. е. переход от одной нотации к другой и обратно выполняется без потери качества модели. Отличие между ними заключается лишь в форме отображения элементов модели. При использовании любого CASE-средства вначале строится логическая модель БД в виде диаграммы с указанием сущностей и связей между ними. Логической моделью называется универсальное представление структуры данных, независимое от конечной реализации базы данных и аппаратной платформы. На основании полученной логической модели переходят к физической модели данных. Физическая модель представляет собой диаграмму, содержащую всю необходимую информацию для генерации БД для конкретной СУБД или даже конкретной версии СУБД. Если в логической модели не имеет значения, какие идентификаторы носят таблицы и атрибуты, тип данных атрибутов и т. д., то в физической модели должно быть полное описание БД в соответствии с принятым в ней синтаксисом, с указанием типов атрибутов, триггеров, хранимых процедур и т. д. По одной и той же логической модели можно создать несколько физических. Например, ERwin 4.0 позволяет на основании логической модели сформировать физические более, чем для 20 популярных СУБД (ORACLE, Informix, DB2, MS SQL Server, Access, Foxpro, Paradox и т. д.). На основании физической модели можно сгенерировать либо саму БД или DDL-скрипт1, который, в свою очередь, может быть использован для генерации БД. Выше порядок действий называется прямое проектирование БД (Forward Engineering DB). CASE-средства позволяют выполнять также обратное проектирование БД (Reverse Engineering DB), т.е. на основании системного каталога БД или DDL-скрипта построить физическую и, далее, логическую модель данных. Кроме режимов прямого и обратного проектирования, CASE-средства обычно поддерживают синхронизацию между моделью и системным каталогом БД, т. е. при изменении модели они могут автоматически внести все необходимые изменения в существующую БД и наоборот. Развитые CASE-средства обладают также встроенной подсистемой поиска и исправления ошибок в модели. Особенно полезна эта функция при проектировании больших БД, содержащих десятки или сотни таблиц, а также при обратном проектировании. Следует отметить, что современные СУБД обладают своими встроенными средствами визуального моделирования данных. Некоторые из них даже поддерживают классические нотации ERD. Недостатками такого моделирования является построение только физической модели данных и невозможность быстрого перехода на другую СУБД, если такое решение принято. Достоинством этого подхода является более полное использование потенциала СУБД, ведь разработчики СУБД лучше других знают ее особенности и возможности. Задача Спроектировать схему двух баз данных и сопоставить поля для переноса пользователей. На фабрике есть две базы данных, одна база самой фабрики, а другая иной организации, которая устанавливала пропускную систему. Задача переносить пользователей из одной базы в другую, если в какой-то из них не существует того или иного пользователя. Но прежде чем переносить, нам надо сопоставить поля и спроектировать связи, сущности. Физическое проектирование  У нас есть 5 таблиц, которые связаны между собой внешними ключами. Таблица QuestUsers хранит в себе пользователей из пропускной системы. Далее идёт таблица Man, которая хранит в себе сотрудников фабрики, эта таблица уже используется только внутри фабрики, кроме пропускной системы. Далее таблица AD-RolesUser ссылается на таблицу Man и хранит в себе роил пользователей, чтобы в зависимости от роли, каждый имел доступ к определённому. Таблица AD_Roles хранит в себе всевозможные роли и на эту таблицу ссылается таблица AD_RolesUser, в свою очередь Ad_Roles ссылается ещё на таблицу с ресурсами ролей. И каждая из этих таблиц с ролями ещё ссылается на таблицу Man, чтобы привязать сотрудника, который создавал ту или и иную запись в таблице. Логическое проектирование       QuestDB EkgfDB Добавление пользователя Список литературы БД WIKI https://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85 БД - https://habr.com/ru/post/555760/ БД Описание - https://proglib.io/p/11-tipov-sovremennyh-baz-dannyh-kratkie-opisaniya-shemy-i-primery-bd-2020-01-07 БД - https://habr.com/ru/post/598760/ |