From
https://www.openqm.com/openqm/what-is-multivalue/
Using a grocery receipt as an example:
In a relational database there would be a record for the particular sale: The transaction table would have a unique transaction number, a link to the customer number (in its own table), the date of the transaction, the time, the register, and a link to the cashier (in its own table.) Then a sales table would have, for each item involved in that transaction, the transaction number, the item code, the quantity, and the sales price for the item. To get the receipt you ask for the transaction or search for the date/time and then go into the sales table, the customer table, and the cashier table, gathering the matching data.
In the multivalue database all of these would be in a single table where the list of items would be on one row for the transaction.
I'd say the multivalue database is better for speed and creating applications as long as the overall structure of the operation doesn't change and there isn't much need to do a wide data-validation. In the relational model it is easy to add another characteristic via an additional table and to ensure consistency as the amount of duplication can be eliminated. For example: if someone fat-fingers "Peeches" into a multivalue database there's not a good way to catch that; in the relational database when the transaction is happening, if "Peeches" is entered, there won't be a matching item code and the error can be detected at that time; likewise if "Peeches" was accidentally added to the Item Code table, that's the only place it will appear and can be edited, repairing all future references without changing any other tables.
I cannot say which is definitely better. The noSQL databases can be faster, but SQL compilation is no slouch either.
Pretty much to convert you need to create the tables to expand the multi-values into rows -or- some newer SQL databases offer array elements within row values.