Transcription
Hooray, colleagues, future students! Good evening! I hope you can see and hear me. I'm glad to welcome you to the open lesson of the specialization course in system analysis.
Today, we will talk about the data stored in databases and even database management systems. But first, I want to check if you can see and hear me. Can you see my image? Yes, you can hear me perfectly. Is the screen being shared? This doesn't happen every time. Judging by the responses from Irina Petrova, thank you for the organization, I can be seen and heard well, and there is a very small delay on YouTube, which is great.
We are, of course, recording this session. I apologize for the two-minute delay, but I don't do YouTube broadcasts every day, and I had to perform some magic. While I introduce myself and tell you about myself, I ask you to do the following: share a bit about yourselves in the chat. Tell me who you are, your name. I see many names already. If you have a job, do you have experience in IT? If yes, what kind? And do you have experience specifically as a system analyst, requirements analyst, or something similar?
And most importantly, what is your goal for signing up for the classes? Typically, people sign up either to learn something useful or to see how the classes are conducted in the community to decide whether to buy or not. We are broadcasting through YouTube, and there is a slight delay after I speak before you see me, and then I will read your chat. So, I probably should have introduced myself first, but then there would have been a significant delay, and you could have been telling me about yourselves.
So, I'm waiting for some responses. The first response is from Philip: "I have no experience, just observing." Well, that's great; a typical applicant! Now, let me introduce myself while you write. My name is Valery Lvov, and I am a system analyst, even a lead system analyst at NSPK. I work in the Mir platform team, dealing with the fast payment system that many of you probably know.
Here are a couple of contacts where you can read about me on approved social networks in Russia. I have been in IT for over 20 years, which is quite a long time. During this time, I have worked as a project manager, product manager, product owner, tester, operational support, technical support, and sales. For the last 10-15 years, I have been involved in requirements analysis in one way or another. So, even though I have worked in various roles, I have been a system analyst for more or less the last six years. I am even registered as a system analyst in my employment record.
I work with a team to gather requirements, design systems, design tests, and deliver systems that are used across Russia and seem to be well-received. Among my discoveries, I have a surprise: I suddenly found out that I am a certified Microsoft SQL Server professional in the field of databases from many years ago. I studied to get certified and even worked for a while as a Microsoft database administrator. So, I think if I haven't forgotten everything, I will have something to share.
The topic of the open lesson is: What is data? What is a database? What is a database management system? Why is it needed, and what do analysts need to know about it?
The agenda for the webinar includes introductions, which we consider to be completed since two people have responded. Great! I will briefly talk about the company TUS, where we will all learn together, and then we will move on to the substantive part of our open lesson.
We will discuss how an analyst designs an information model, and at the end of this event, we will talk about the database that an analyst should use for their benefit. First, what is a database? Because not everyone knows. Well, Anton knows, but probably not everyone. Typically, students don't quite understand what happens inside a database, what a database management system can do, and what it cannot do.
We will look at what an analyst should do with it. Again, we will talk about the course team that you are considering, the training program, and we will look at what job vacancies exist in the world and how they relate to our course. Finally, we will summarize and reflect on how productively we spent this evening.
Webinar rules: The rules of the webinar slightly differ from what we do in TUS because usually, we conduct not lectures that are listened to in one direction, not streams, but interactive classes where the teacher explains something, students do hands-on work, and the teacher supervises. So, we generally have a normal live class, seminars, just through the internet via Zoom.
This is not a lecture where a person talks while others listen and nod. Such a format is not practiced. There is a series of questions and answers that need to be thought about, but this is an extreme case. Therefore, I chose an overview lecture, so to speak, about what a database is and how they work as an example of an open lesson.
Yes, it is a bit atypical, but nevertheless, you can see how we conduct our classes. At least I hope we are keeping to the timing. Nevertheless, I ask you to participate actively and ask questions in the chat because I see them. I may answer them immediately as they arise or postpone them and answer later if it is appropriate.
So, please ask questions in the chat. Unfortunately, I cannot ask you to raise your hand and speak out loud; it is very difficult to talk alone for an hour and a half without hearing any other voices.
On to the company TUS. Let's talk about where we have come. TUS is an educational project that has been operating in the Russian market for over six years. Initially, we started as a company that trained mid-level specialists in the field of development, design, administration, and training.
We focused on those who had been in the field for a while to elevate their skills. This was our niche, and we did this for a long time. Now, at least half of our courses are aimed at already prepared specialists who want to enhance their skills.
However, knowing our reputation, we have been asked for a long time to finally engage with beginners who are just entering the profession or even have no experience in IT. Therefore, we opened a whole school for young specialists who have not been in IT.
This includes two courses: System Analyst Basic and the specialization in System Analysis, which starts from the same Basic course. You can join either without IT experience but with a desire to do so or with non-IT experience, such as a database administrator who can retrain as an analyst or someone from technical support.
This is wonderful for people who already have some industry experience, for example, someone who worked as an accountant and suddenly found themselves in a project implementing a new ERP system. Since they work as an expert in their domain and participate in gathering and formulating requirements, they effectively become a system analyst.
Here, they can learn and become certified and classified specialists. Besides ordinary individuals who decided to invest their money in our course and increase their value, we have many corporate clients. Many companies send their mid-level specialists to us for training, as well as juniors or entry-level specialists, so we can train them in the System Analyst Basic course.
Typically, there are about four specialists in a group who come to study under the B2B program. We have many different courses, and naturally, I advocate for system analysis, of which we have several.
There is the System Analyst Basic course, a specialization consisting of two courses, and there is also a specialization consisting of System Analyst Basic and Business Analysis. For example, there is a System Analyst course. All of this can be found in the syllabus.
What is specialization? Besides analysts, we have developers of various kinds. We have those who deal with data analysis, not just system analysts. We have testers, and of course, we have DevOps and other engineers. We teach all kinds of IT specialists.
As for the course direction, I just mentioned it. Let's look at the numbers: we currently have over 600 active teachers. During the time TUS has been operating, we have had about 1,000 teachers. Well, one of those six living people is me.
Oh my, over 20,000 graduates have completed training in our programs. A huge number of people have already gone through our course in the two years since it has existed. I can name dozens of people by name; sometimes I even meet them somewhere.
A provocative question: if we have students from our current System Analysis courses, please write your last names in the chat. I remember many of you, and the rest can write a suitable number in the chat if you have studied with us before. If you haven't studied with us but have heard the term "database" and decided to check it out, please let me know.
And one more small disclaimer: you can manage the teacher here and in other classes. You can ask them to speak louder, softer, faster, slower, or repeat a thought that didn't come through. But you can only do this in the chat.
Hint to me that I am getting carried away, that I am speaking quickly, that I am speaking complicatedly, or that I am stating obvious things that are uninteresting to everyone. Feedback can be given not only after the lesson but also literally during it.
So, data, databases, and database management systems: what are they? What kind of beast is this, and how do we approach it? First, we need to set the goal of our lesson.
By the end of the life cycle of designing the information model of our application or program, it is assumed that this is just one of the lessons where you work on the information model. Before this, you identified domain entities, created a data dictionary, and designed, for example, a diagram or class diagram.
You have already understood what entities you have and how you will work with them. Today, we will talk about what a database management system can do and even if you are not allowed to access it, you should be able to call a database administrator and say, "Don't forget to do this; it's important. I know this thing exists."
Or, conversely, if they ask you questions, you will understand why they are asking and where you can provide value.
And the most important goal for me is for you to understand what this looks like, to have some opinion about webinars, and finally, about the teacher. Why not get personal?
So, right on time, let's go! The first topic is designing the information model: how did we get here, what are we doing here? First, please tell me what an information system is in your understanding.
What is the purpose of designing data that resides within it? What is an information system? I have a couple of good answers as well. I am reading the chat; it's interesting.
Konstantin introduced himself as an intern analyst. The interesting thing is that the word "analyst" is used in two contexts. First, there is data analysis, which Konstantin is apparently involved in, where large data sets are collected and analyzed, involving machine learning, artificial intelligence, and similar things.
The second analyst is the system analyst, who deals not with analysis but actually with system analysis and requirements analysis. Naturally, data analysts want to know about system analysts, and system analysts want to learn a bit about data analysis.
So, Anton wins the first prize: indeed, any system that contains and processes information. Yes, plus, in fact, it also receives information from somewhere, processes it, stores it, and outputs it externally.
If we can call a system that works with information an information system, we can simplify it by saying that an information system is any electronic device that plugs into a socket but is not designed to heat water.
While someone else wants to add answers, Anton asked an interesting question: is a system analyst more of a database architect, a developer, or a technical writer? The choice is small. A system analyst is primarily a system analyst, but they do indeed combine many specialties, slightly encroaching on others' fields.
So, they are indeed a bit of an architect; they design the system. A database developer, I think, is less so because there are usually specialized people who are good at creating databases if you tell them how to do it.
And telling them how to do it is what we should do. A technical writer is probably someone who should be in our team to document everything. So, no, a system analyst works with requirements and system design more or less as you suggested.
So, yes, we have an information system that processes information. We decided to create a system. A client came to us with bright eyes; they have an idea to create a social platform where people can exchange free stuff.
Let's try to design something like that. It's like Avito, but without money. In fact, similar systems already exist and work, so I didn't make this up.
In our classes, we use a cross-cutting case. We don't have a system for exchanging stuff; we have something else, and we work on designing that system from the first to the last class.
Today, we will try to design a very social system where people register, post unwanted items, and someone wants to find them because they need an old coat. They want to socialize, and then we gather statistics to show targeted advertising.
After all, it's not entirely free. I apologize for the business proposal I came up with in 10 minutes just to have something to design further.
Let's look at some requirements. Suppose we described functional requirements for the system, and possibly even user requirements: what a user must do to ensure these functions.
One way to capture requirements and develop them is to write cases, such scenarios that describe user behavior and system responses. The user does something, and the system responds. The system asks, the user answers, and so on.
There is a format; we have lessons where we design these cases, both theory and practice. In the end, there is also an open lesson, which is purely coincidental, where I explain how to design these cases. You can Google it on our YouTube channel.
Now, let's focus on the user performing some operations and how the system responds to them. Let's look here and think about where we can identify information entities, meaning our information objects that should be stored in our possible database or at least in the system.
And actions will be performed on them. I suggest looking and responding again in the chat. I will take a pause for a moment. What actions can be taken, and what do these actions conclude?
Let's read carefully from the first to the sixth point, paying special attention to the nouns. The stream has been going for 20 minutes; someone should like it. That's a success!
I don't see any responses yet. Analytics is about courage, I remind you. I will show the results while I highlight the nouns we have here.
The user describes the item. I don't know what to call it; maybe a product? Something like that, junk that they have. The user describes this item in text.
So, the item has some attributes, like a description. The user attaches photos and videos. Aha, so there are attributes for photos and videos. The system suggests categories, which is also a good option.
The system shows, well, probably the same item, just simplified. The user confirms some actions. And probably our listing is free, saved, and available for search.
Yes, the listing is saved and available for viewing. Since it seems that the same item is named differently, we should step back and clarify in our dictionary or glossary whether this is the same thing or, from the perspective of the requirement owner, if these are different things.
At first, it was an item, then it became a listing. Maybe it has a different meaning. It's a good reason to clarify. But if we look deeper into the requirements, we can see that there are other words.
There is the word "user." Apparently, this is also some kind of information entity. It's not just a person sitting behind a keyboard with a login and password.
Oh, by the way, the login and password need to be stored somewhere. There are also nouns like "category." I already associate it with the item. We probably need to store the category and somehow operate with it.
Maybe it's some kind of dictionary that contains standard data. Philip, good suggestion! Maybe there are several items in the listing. We clarified the requirements by asking the question, "What if?"
We didn't hesitate to return, but in my listing, as the requirement owner, I say that one listing is one item. It was an item lying in the closet, and when it is posted in the system, it is called a listing.
Okay, we clarified the terms. So, we have items, we have categories, we have users. It looks like we have three information entities. We have identified them, and now we need to do something with them to store, retrieve, and process them in our system.
For this, we created a data dictionary, which is beyond today's lesson, and probably created a conceptual model. To start, designing information entities begins with a conceptual model.
We simply rewrite what information items we have. We have users, we have attributes, properties. What do we need to know about these users and the listing? We need to store, process, query, or display some logic according to these attributes.
Suppose we learned that we need to know the user's name. The first name and last name are unclear. We need to clarify what contact details are needed. The city of residence is also interesting.
Should they write it themselves or choose from some directory? What do we need to know about the listing? Essentially, the description of what is being sold, some name with a description.
Of course, we need to know who is transferring it to whom, so there is a connection with users. And some conditions for the transfer that they described, for example, in the chat.
Well, our client described their vision of the requirements. From their perspective, this is how it looks: a bunch of questions for clarification. For example, what is a name? Is it a display name, a login name in the system?
Is it necessary to have a last name, first name, and patronymic, or is just a first name sufficient? Should we store the first and last names in one line or separately? A bunch of questions!
But nevertheless, we understood that both the user and the listing have a set of attributes that need to be obtained from somewhere in the database, in our future system, stored somewhere, and then displayed.
This seems like a typical task for an information system. Let's move on. Based on what we just created in our conceptual model, we take it and draw a logical model.
We understand that the entities have these attributes. Fine, we won't touch them for now, but there are also relationships between the entities. The listing is associated with the user; the user creates listings.
The listing is tied to the user. Great! We can immediately design what the cardinality of these relationships will be. These numbers mean that a user can have from one to an infinite number of listings.
There can be zero; they just registered and did nothing. But a listing can have one or two users. Why can't it be zero? Because someone has to create the listing, so at least one owner exists.
When a second person wants to acquire it, the buyer will appear. So, only one or two users can be associated. Aha! Excellent! We will need this when we design some tables in our database.
What else can we see? We saw that there are categories and some cities. Categories should probably be stored somewhere as a dictionary and displayed as a list so that a person doesn't have to enter new categories every time, like "computers," "computers," "computer," when they give away a computer, etc.
It would be difficult to navigate for someone browsing. So, we should pre-fill the list of categories. Each listing can be assigned one or more categories, at least one. Accordingly, each category can have zero or many listings associated with it.
Not a dictionary, but a reference book. Well, a reference book. What else relates to the listing? The listing has a list of cities. The listing is, of course, in some city.
It may coincide with the donor's city, or it may not. I don't know how. Let's think that it can be different. So, we already have four information entities: a user with some profile, a listing with a description, a list of categories, and a list of cities.
We assume what data will be stored in our system, what we will operate with. Based on this, we will create what is called a logical model. We will think that this data should be stored somewhere.
Well, we have an interface in the system, of course. Let's look at it this way. There is an interface; a person looks at a computer, sees some page or application with some data, enters something there, uploads photos, or browses.
There is a special web server called the presentation level. A special computer or service is dedicated solely to producing for us what I take or refuse. There should be some logic; we need to write the program itself that will operate there.
If a person says, "Yes, I take it," they click a button to register the listing, attach it to something, and refuse it. So, there is some logic.
There is also a third level of logic, the business logic level, where some logical operations occur. This is the programming code that is called the backend. This is where the presentation level will be called the frontend.
But these operations on listings, searching, and dictionaries happen with such data. So, somewhere the program still stores its data. Therefore, there is another deeper level that no one sees while working with the application: the data storage level.
Great! The program operates with data, and somewhere it stores them. Let's think about what this data is. If we delve into the encyclopedia of database technology, there is a definition that I tried to rephrase: a database is a collection of data organized according to rules located on a computer and reflecting the state of something.
Naturally, these data are needed for something. The data we invented: listings, users, dictionaries with cities and categories. All this closely resembles the definition.
Indeed, it is a collection of data, not just one record but a collection. This thing is organized according to some rules. We even know that it lies in different, I don't know what to call them, storage pieces.
Users are separate, something else is separate. Naturally, all this is on a computer, not in a paper file or on graph paper. It reflects the state of the user, the state of our entire system at the current moment.
And it is needed for something. To allow a listing to be posted, to find a listing, and to be happy. In fact, to gather information about users and show good advertising.
So, we don't know how our data is currently stored. We know that somewhere deep down, three layers below our representation, they exist. But judging by the definition, we need this database.
What things do we want to store? Let's think. I will make a dramatic pause for 10 seconds so you can write something in the chat while I continue speaking.
The operation history: Anton, excellent! Text, numbers, and so on. Yes, I asked a question that can be answered in different ways: text, numbers, and so on.
The list of our users, the list of listings. This indeed resembles some kind of table where it will be recorded that listing number one is a sofa, and it is given to someone, and it has such a description.
All this looks like a table. A brilliant idea! Why not use Excel to store all this data? Why not? Someone invented Excel; it's a good thing.
No one argues. The program will access it, I don't know how, but probably there is some driver to read and write to it. Great! The whole idea seems to be done for us.
Our transfer of junk is essentially tables. Is this a good idea? Well, in principle, a database does resemble a table. It may be an Excel table or just write this file and put it somewhere on the server's hard drive, a file where our program will write the data related to our listings in a specific order.
The date of posting, who posted this listing, we have the name, patronymic, last name of the user, the description of this listing, and the city where this listing is located.
So, in the form of a simple text file with a special markup called CSV. A brilliant idea! Excellent! We don't need to do anything; we just need to write a program that can write to this file in a specific order and read from it in a specific order and retrieve data from it.
In principle, this works. Such a thing can be done if you have, roughly speaking, one person accessing it at the same time. So, everything is fine, and the files in the form of CSV can represent a kind of database.
If you have a few people and not too much data, Excel can also be a database. Moreover, now, for some reason, I think it doesn't exist anymore, but there was a database called Access, and it even worked with small systems for 10 users.
So, you can organize it with some limitations. So, a brilliant idea to store this data in a specially formatted file or some Excel table.
Great! It will work. Excel is indeed a database consisting of, as it were, one table. I don't remember if Access was exactly that, but historically, it was the first database I saw, and they tried to teach me it.
Oh Lord, how does a database look in German? What is the word for a primary key? Don't even Google it!
So, does our database resemble an Excel table? Yes, in terms of design, it is essentially similar: several tables that are interconnected. Don't be afraid; nothing new appears in these databases.
From the perspective of an analyst who designs, are there other additional functions worth using or at least knowing about? There are many, and you need to think about them and discuss them with the database designer and administrator.
This is not explicitly the analyst's job; it requires a special person. However, there are startup projects where there is an analyst, a tester, and two programmers. Someone has to create this database, and whoever has the courage will do it.
So, does a database resemble a table? Yes, it does, but it is much more than that.
Let's take a break. I will look at the chat to see if I have answered all your questions and jokes. Anton is sharing a lot of wonderful things about databases. I see that he is an experienced person.
We could have tried to do the open lesson together. If you have questions, now is the time to write them.
So, we just talked about databases that resemble tables that are interconnected. But if we look at the resumes of our senior colleagues in job descriptions, there are some scary words related to databases.
It would be good to at least respond adequately to these words at the Basic Analyst level, but studying NoSQL databases is not included in our volume.
So, just to broaden your horizons, I will say a few words to include something in your resume. The tables we just saw are relational tables. "Relational" in English means "connection."
Our tables are interconnected in a specific way. You can make a query on one table, a query on two joined tables, or search across several tables. Yes, however you want. The main thing is that the data is structured; they are described.
A username is always a string. What else do we have? Activity is always a boolean. The tables are interconnected, and those requirements we talked about for transactional systems: atomicity, consistency of data across all nodes, isolation of operations from each other, durability of storage, are wonderfully ensured in these relational databases.
What we just talked about are relational databases, or as you all know, at least one representative of these databases, starting from the largest, Oracle, to the more accessible systems you have probably seen, like MySQL.
They differ in various ways, providing some transactional properties, slightly different query languages, and dialects. Finally, they are developed by different companies, have different costs, and some are available in Russia while others are not.
Okay, let's expand our consciousness, and now I will start to deviate from the principles I proclaimed recently. There are also other databases called non-relational databases, which are not just tables or not only tables.
The term "NoSQL" does not mean the negation of SQL; it is an abbreviation for "not only SQL." You can access them using SQL language. There is a theorem called the CAP theorem, which states that with large volumes of data and distributed systems, it is impossible to achieve all three parameters simultaneously: consistency of data, availability of data at each node, and partition tolerance.
If we split the connection between Russian and American servers that should copy data between them, each of them works independently. However, it is not guaranteed that the data on them will be the most current.
For large systems with large amounts of data, it has been proven that it is impossible to ensure all three criteria simultaneously. You can only ensure one or two. The triangle shows how this is done across different databases.
Why is this important? If we want to organize a system at the level of Amazon, we probably need to give up something: either consistency, availability, or partition tolerance.
Although this is unlikely, we need to consider what will be more important and what consequences will arise from giving up one. For example, Amazon, which is huge, may have inconsistent data.
For instance, there is data about the availability of a product in stock, and simultaneous purchase requests may occur even when the product is out of stock. The purchase requests may happen at the moment when the product is already out of stock, but the data has not yet been updated.
This is a problem for the system, but it is not critical. However, the user can see the product in their cart within seconds. For business, this is more beneficial.
So, in large distributed data systems and with large volumes of data, it is normal to violate some principles of consistency, availability, and partition tolerance.
There are database management systems that violate some of these principles and are structured differently. There are several classes of these databases. Again, as a Basic Analyst, you just need to know that they exist.
You don't need to know how they work in detail; otherwise, you would already have that experience. You will gain that experience later, and you will not need to attend these open lessons.
For now, just understand that such systems exist, and they allow for slightly more complex tasks than just storing tables. When you get to projects and someone tells you that you have MongoDB, you can say, "Yes, I've heard of it; it's document-oriented."
You may not have worked with it because you are a junior, and it is still early for you, but you will be happy to study this system with others. It is very likely that no one else, except for one programmer, has worked with MongoDB yet, and that is normal.
So, briefly, we are running out of time. What types of databases are there? For example, there are key-value stores. Essentially, this is a table consisting of two columns, where the first column stores a unique key, and the second column stores the value that can be retrieved by this key.
Some of these databases are stored in memory, so they work instantaneously. For example, in the fast payment system, you can find out something about a client based on their phone number.
This needs to be processed quickly because it is a national-level system with a huge number of requests. We need to perform one of these operations and many others very quickly.
The second type is column-family databases, where the key is both a row and a column simultaneously. If I'm not mistaken, it is called a sparse matrix. This is also an interesting structure that works differently and is well-suited for indexing and search engines.
The well-known Yandex, which can store indexes and search web pages, probably holds something similar at its core. From personal experience, we use these databases, which scale across many servers with built-in methods that allow for instant searches based on some key.
Interestingly, almost all of them are developed by companies. Then there are document-oriented databases, where we can treat documents as structured parts.
You can search not just by simple string matching but by specific fields stored in one cell. The most famous of these is MongoDB, which is often used.
There is also a fantastic thing called graph databases that work with relationships between nodes. They are wonderful and are used in social systems.
For example, I want to know: "Show me all the friends of this user, or show me all the interests that the friends of this user have listed in their profiles."
Can this be done in our relational database? Yes, there is a users table, a hobbies table, and a friends table, probably with some connection between them.
You can select your friends, then select their interests, and then select the friends of your friends, and so on. A graph database can handle such queries efficiently, traversing the tree and collecting the necessary values.
This is a cool thing, but I am not sure how useful it will be for you in the near future. It works in some intercontinental or intergalactic systems, but knowing about it is undoubtedly necessary.
There are separate courses on these databases, and they spend about a month on each representative. You can look into something in-depth.
In your resume, you can write that you have an understanding of NoSQL databases, something like that.
If we have 15 minutes left, now the most important question: as an analyst, why do we need all this besides broadening our horizons, which is also useful?
An analyst, together with their colleagues, such as a senior developer, architect, and possibly a database developer and administrator, sits down to solve several questions.
First, they design the schemas that will form the basis of the database. They create a conceptual model, which we started with, remember? Two squares.
They create a logical model describing attributes and then create a physical model of the future database, where they will describe which attributes, with which constraints, how they will be interconnected, and how they will be stored in the database.
This is practically the work of an analyst. If a specialized database designer comes in at this moment, well, that is a separate specialty. But if they say, "This is mine," you, as an analyst, will write at a more abstract level.
Great! You have a partner to whom you can hand over your work. Together with the architect, you think about the load and estimate how much data will be stored, what access you need, and what fault tolerance is required.
So, you formulate non-functional requirements for data storage in databases. After answering all these questions, the architect will say, "Well, you probably need this kind of producer, approximately these servers, and this is how they will be interconnected."
What else? If you have a startup and no one dares to create this database, you can take that SQL browser and bravely create a table.
If not, well, this is the beginning of the operator who will create the database. Finally, when you have launched the application and invited your friends to exchange an old sofa to test it, it is called the "Friend Family Test."
After they click buttons, it would be good to check the database you created to see if the sofa, friend one, and friend two are indeed recorded and if the transaction was successful.
If everything works well, as a system analyst, you will analyze the data, looking at which cities your requests come from, what items are being exchanged, or something else.
Okay, then learn the language called SQL, attend other courses on data analytics, and analyze your system at the business level.
What users are using it? Please vote in the chat on how clear it is to you what the analyst does with databases, how they design them, and what the life cycle looks like.
Is it a conceptual model, some attribute development, relationships between them, one-to-many? Okay, do you understand what a database management system can do, even beyond your analytical competencies?
All these stored procedures, backups, sharding, and finally, the most important thing: did you manage to feel how webinars are structured?
For now, I won't ask if you want to buy the course, but do you understand the atmosphere, the style, and the people who will surround you in the coming year?
Perhaps you have achieved some goals. I don't ask for answers, but I hope that the answers are in your eyes.
I remind you that the next specialization course starts on the 28th. We all have time if we want. The next open lesson on what analysts do in projects will be led by Maria Krasavina on the specified date.
Yes, this is what Maria is talking about. I just screenshotted the landing page. The most important thing is that in all our classes, we collect feedback on specific lessons, topics, sections, and teachers to adjust our classes accordingly.
We ask everyone to provide feedback, and it truly allows us to correct our course not only for future cohorts but also for you. We can do this in real-time.
So, in the chat, there is a link. Please go ahead and leave feedback about the open lesson, write what you liked, what you didn't like, and whether you would attend more such lessons.
The most interesting responses will be conveyed to me by the methodologist, and I will also adjust my open lessons based on what you say.
Now, I thank you all for your attention. I apologize for running two minutes late. You see, I finished four minutes late. I think this is within the margin of error, and I believe both you and the methodologists will forgive me.
So, someone asked how interaction between different databases occurs. I am currently answering questions.
What is the question? Both use two different dialects of the same language. You can write some integrating application that, I don't know, finds data in one and puts it in another or part of the data in one and part in the other.
For example, you can write an application that integrates data from one source and queries from another. Everything is great!
You can do better, actually. Integration may not be needed between databases but between the systems themselves. One system is for our free junk, and the other is a banking system.
You don't need to integrate between databases; you can create a button to order a loan to get a free item. Integration can be done, but that is on another level.
It will be an integration API, some REST API. Great! I always advocate for REST because it is trendy, popular, and well-known.
As an example, please formulate the requirements for the Avito task. Yes, I have the requirements formulated somewhere at the beginning.
We need an information system where users can exchange items. The system should search for and retrieve items. Users should be able to communicate within the system. The system should allow for annotations and collect statistics.
All requirements that start with "the system should" are functional requirements for the system. The developer will not take them into account.
Of course, you will further detail the requirements and write them as follows: "The user will do this and that," and based on this case, you can draw the system interface.
That is, a window or form where they will describe it. From here, you can understand what data is needed in the system: one field for description, another for name, and the second for photos and videos, which will be blobs.
And from here, you pull the data that is passed to the database and saved. The developer will take this into account. "Look, these are the interfaces. This is how it transitions through these buttons. Each button corresponds to such business functions or sends such requests."
He will take it. Well, how to put it into work is a separate webinar. Please, we won't discuss that today.
Colleagues, thank you for your attention. Thank you for spending an hour and a half, even a little more, of your wonderful time with me. I hope to see some of you in the course.
Marina, I remind you to do your homework. Thank you all! I look forward to feedback from those who registered on the platform.